A wide variety of service provider devices provide services to users through the use of configurable assets. Typically, the service provider device is configurable as well. A common example of a service provider device is a telecommunications switch, such as a private branch exchange (PBX) device, that services the configurable assets, such as telephones, that are connected to the device. The distinction between a service provider device and an asset as used herein is that the device is an entity that provides a service and that is owned by the organization or administrators managing and providing the service, while the asset is the entity that receives the service provided by the device and that is owned by, or configured for the use of, an end user.
The assets are primarily controlled by the configuration of the device, for example, the switch. However, a limited amount of control often resides with the end user of the asset so that the end user can manage and program the features offered by the asset and the device.
The users of these assets can program them directly or through the use of software applications to alter the default functionality of the asset. For example, a user can often program the keys and features of the user's telephone to behave differently from other telephones.
Similarly, administrators can program a telecom switch to support one set of features versus another set of features, or to alter the accessibility and behavior of the set of features available to the assets controlled by the switch.
Often, help information regarding features on assets such as telephones is provided in brochures that the user misplaces or files away. Other methods of providing online help may provide help on all possible features. This may make it more difficult for the user to zero in on or to find help on a feature that is specific to them. Also, when all help is provided, the user may see a feature that is not provisioned for them that they would like to use or that they have questions about. If such were the case, that user might take up more of the administrator's time and the administrator might have to explain to the user a feature that this user is not even allowed to have—as a policy decision, for example.
Typically, on-line help is an electronic version of all feature operations. In a configurable asset environment, only a limited set of all features may be implemented. So in either a printed document or on-line version of all feature help the user is presented with much more information than is needed and has more difficulty navigating to the specific help that is needed.
In other instances, the issue extends beyond a set of features that are made available or that are denied to a user. Feature behavior can change dynamically because of programmatic changes introduced on the service provider devices or on the assets serviced by the devices.
It is thus a challenge to provide help information on features, commands and operational behavior of an asset to its user subject to ever changing conditions of the asset and the device that controls it. The user often has to wade through pages of manuals, which may also be lost by this time, to get help on a feature. Furthermore, such information may only be useful for providing help on static features, that is, features that are either enabled or disabled but whose fundamental behavior does not change. Users would not have any help or guidance on how to use or work with features that change dynamically. An example of a dynamic feature is the numeric prefix that often needs to be dialed to get to an external phone from an internal telephone line in a company.
As network and communication devices become more versatile and programmable, it is desirable to present the user of these resources with an accurate guide to using these features. It would be useful to provide the user with specific help information in accordance with actual assets used by that user, for example, in a distributed system environment. At the same time, it is desirable not to burden the user with complex technical details, which might even be outmoded in the wake of dynamic programming of asset and device functionality. It would be desirable to limit the security risks and to reduce the chance of contention over access to features by focusing help information on those features that are both operational and that are within the purview of the end user.